House Bill 1668 was introduced in the house in March of 2019 and signed into law in December of 2020 as Internet of Things Cybersecurity Improvement Act of 2020 or the IoT Cybersecurity Improvement Act of 2020. You can read the bill at https://www.congress.gov/bill/116th-congress/house-bill/1668 it’s a pretty long way of saying “hey these IoT devices are computers.” But it certainly needed to be said.
Background
Grace Hopper developed the first standards for testing computers and programming languages for the Navy, protecting the government in the wake of rapid innovation. Those tasks are now handled by the National Institute of Standards and Technology (NIST) and the result is often guidelines on deploying computers into government locations. Companies and large enterprises then look to the NIST guidelines as the gold standard to secure devices, sometimes choosing to be more stringent or to let a few things go for the sake of useability. Let’s make no mistake that IoT devices are computers and should be treated as such with regards to securing them.
Based on the success of the Broadcom System on a Chip (SoC) in the Raspberry Pi project, nearly every device gets bootstrapped with a cheap ARM SoC, some have decent security, others not-so-much. Many organizations don’t seem to realize that an IoT device, because they’re now just computers with IP addresses, then needs to be handled with the same high standards as a computer on a government or corporate network. NIST produced a guide, or Core Baseline for IoT device manufacturers last year but smart microwaves and coffee pots and electrical outlets continue to make their way into environments and so we needed to make clear to the environments that these devices shouldn’t be purchased unless they meet the standards.
A few things have happened over the past few years that cause us to start thinking of how to classify the devices:
There has been an explosion of vendors creating devices. There are those we’ve never heard of and those we have, often with those we haven’t heard of getting white labeled or embedded by those we have.
The price of devices has dropped to be on par in some cases with non-automated devices.
There has been a pretty concerted effort to move to IP-based devices from the older protocols like Z-wave and Zigbee which required a bridge to control them.
The centralization of command and control devices to Amazon (Alexa), Apple (Siri), and Google has led to devices being easier than ever to set up in homes and so more ubiquitous.
App vendors have provided SDKs that allow a device manufacturer to release devices without having to worry about software (e.g. VeSync).
The rapid interconnectivity of all of the platforms with Application Programming Interfaces (APIs) where controlling a web of devices in a home has packets traversing the planet, bouncing between perhaps 5 vendors in 5 countries in the half second it takes for Alexa to turn my Christmas tree on.
The central hosting of controllers so the device itself sends commands to a cloud service which sometimes gets multiple updates to the code per day meaning a specific version can’t be “approved” by an information security team (in fact I’ve spoken to a few device manufacturers where there’s just one engineer doing all of this back-end work so some code isn’t in a real repository or versioned).
Most of the people who deploy devices aren’t splitting them out into their primary network any more, giving a potential attack vector into the primary production network.
The advent of 5G introduces the risk devices go into production more easily than ever, with greater connectivity to the outside of government and corporate walled garden networks than ever.
There are a lot of cost savings, increased physical security, better usability, and so much more behind having IoT devices start popping up in environments. It’s a good thing. However, this bill acts as a reminder to make sure every device is secured (e.g. to make sure endpoints are protected, mitigate against persistent threats and other malware, etc). Additionally, any time a statute can provide clarity, technical innovations can flourish more freely and do so safely.
Enterprise Impact
I have yet to see a full end-to-end automation platform that rivals what I can do at home that I would consider government ready. But by clarifying the requirements I would expect a few organizations to release new tools that make it possible. This is similar to what we saw with Apple and other mobile devices as they started to get rolled out into government and enterprises. The device manufacturers allowed Mobile Device Management (MDM) vendors to fill the gap created between NIST guidelines (which in many cases we helped write) and the operating systems.
The challenge with IoT though is that there are so many vendors. So I expect to see a couple of more corporate or security conscious vendors emerge who have good enough security to actually make someone at NIST want to use the devices at home. IoT devices have reached success in the home and as with many grassroots led evolutions in technology, there is a buying tornado coming in enterprises for those who can appropriately secure devices.
What to Expect from NIST
Realistically, based on the history of NIST, I would expect guidelines to include some general technology recommendations such as all devices should “require complex passwords”, “all devices should maintain the latest version of software” and “only allow each user the minimum level of permissions required to complete a given task” that get increasingly technical and specific to IoT platforms, such as:
All devices should scan the checksum of the operating system on the device and if altered from the known required checksum the device should go offline, alert an administrator that it might have been compromised, and/or flash back to a known good image of an operating system.
Use of devices in closed networks is preferred. All vendors that leverage cloud services should be FedRAMP compliant, which will likely result in a race by vendors to get onto the FedRAMP Marketplace.
Devices that communicate with external services over IP should run on a separate network and all transactions should be secured with a minimum TLS 1.2 with compliance for RFC 8446 when TLS 1.3 becomes ubiquitous.
All vendors that have third party endpoints to enable API communication with other platforms, to enrich features and data, and power assistants (e.g. such as voice assistants or single pane of glass automation services) should leverage keys from a federated identity provider that only offer access to data required to process a specific request and each field accessed should require an entitlement, or explicit acceptance of that field.
All organizations for approved vendors will need a Data Processing Agreement (DPA) and each downstream vendor will need one as well, to protect Personally Identifiable Information (PII) and data stored in the systems.
All devices should be kept at the latest firmware, or the latest validated and accepted branch of the firmware.
Where legacy IoT protocol devices (e.g. Z-Wave electrical meter recorders or Zigbee ice or water sensors) exist that require TCP/IP connectivity to bridge protocols, those devices should be paired in a way that prevents devices that are not the bridge from communicating and the bridge should be secured and follow the same requirements and guidelines that exist for IP-based devices.
All devices that ship with a voice assistant embedded must have a physical switch to disable the voice assistant (e.g. an Ecobee thermostat with embedded Alexa).
Stringent vendor requirements, possibly managed by the GSA.
The ability to manage devices and report on them en masse (e.g. using a device management solution).
Long Term
The challenge here is that due to the multi-cloud approach taken by many existing vendors prosumer services often don't translate well to government and enterprise. For example, see https://www.ietf.org/proceedings/77/slides/intarea-7.pdf.
Many of the vendors out there will call two to five microservices that might be hosted in the same number of countries across the same number of vendors. Some of which might have been copied from the GitHub of some rando no one has ever heard of before (like me).
Therefore, what I would love to see but don’t expect soon:
Dissuade the use of devices coming in through shadow IT channels such as non-IT departments ordering devices such as voice assistants without taking into account whether they are approved for use on networks. Having said this, fingerprinting for those vendors is simple in a standard LAN or wireless network and so I could see that becoming a requirement. The rollout of public 5G networks could cause some headaches there, so technology similar to rogue access point detection may be required.
Require routine key exchanges for hosted services to access data (e.g. using the AWS Key Management Service, or KMS).
Penetration testing for all production endpoints.
The ability to have a complete walled garden system with zero communication from the outside.
Deep packet inspection for all data traveling in and out of a device in order to prevent arbitrary VPNs over otherwise trusted ports (for example, Certificate Pinning obfuscates traffic
Ultimately, I see a general vendor guideline being issued and as a few organizations/vendors achieve a level of required security I could see NIST doing a couple of checklists that match what we see with the Mac (e.g. https://nvd.nist.gov/ncp/checklist/972 whose authors we interviewed in this episode of one of my podcasts http://podcast.macadmins.org/2020/06/28/episode-172-you-have-60-seconds-to-comply/ ). Then the security community can have a field day breaking things and helping to refine the requirements while digging up their presentations for the next Black Hat and Defcon.
Комментарии